home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 3007 < prev    next >
Encoding:
Text File  |  1996-08-06  |  2.7 KB  |  70 lines
  1. Newsgroups: comp.object,comp.databases.object,comp.lang.java,comp.lang.smalltalk,comp.lang.c++,comp.lang.eiffel,comp.lang.objective-c,comp.software-eng
  2. Path: gamp.hacom.nl!news
  3. From: albert@gamp.hacom.nl
  4. Subject: Re: Data-driven vs. Behavior-driven OO Methods: a Non-Issue?
  5. X-Newsreader: Gnus v5.0.10
  6. Sender: albert@beowulf.gamp.hacom.nl
  7. Organization: We aren't! Should we, then it's SW, Education and Advice.
  8. Message-ID: <86n37i3ie4.fsf@beowulf.gamp.hacom.nl>
  9. References: <4dhop7$3aj@suez.iconcomp.com>
  10. In-Reply-To: dsouza@suez.iconcomp.com's message of 16 Jan 1996 21:00:55 -0600
  11. Date: Sat, 20 Jan 1996 17:06:43 GMT
  12.  
  13.  
  14. Desmond F. D'Souza writes in  <4dhop7$3aj@suez.iconcomp.com>
  15.  
  16. > There has been much controversy and discussion about methodologies
  17. > that are behavior-driven vs. those that are data-driven, with
  18. > OO-"purists" arguing vehemently against data-driven approaches. In
  19. > this paper, we suggest that the difference may be smaller than often
  20. > thought, if we adopt a simple definition of a "type model".
  21.  
  22. > Paper available:
  23. > <A HREF="http://www.iconcomp.com"> On the Web</A>
  24.  
  25. I have got the paper, (first one in a series of 1)
  26.  
  27. It start great:  (free abstracts)
  28.  
  29. "There are two aproaches ... but ussing the `type model` there are
  30. simulair".
  31.  
  32. And: "Using the (new, our) Catalysis solves al problems."
  33.  
  34. After the introduction and some examples, that line is gone !
  35.  
  36. I'm sorry to say so, but it IS a nice story about nothing. Some new
  37. words and myths are introduced, which are solved by renaming them.
  38.  
  39. One example is about a "Stack", which IS a relevant one. 
  40.  
  41. That examples says: do not just say a stack is " ....", be specific. 
  42.  
  43. I thing we ALL know that. It is like old good programming: 
  44.                 printf() should behave as printf!  
  45. But there is hardly a need to specify that. So is a stack. it should
  46. behave like a stack! So all counter-examples of the paper that decribe
  47. a FIFO, ar a list or ... are no stacks!
  48.  
  49. It's so simple: a strack is only a stack if it behaves like one.
  50.  
  51. But it is also true, some more complex "objects" shoul be described
  52. better. But do not make the mistake to solve this by specifing it by
  53. other "informal words" That just hides the problem, it doen't solve
  54. it.
  55.  
  56. So, back to printf(),: it ain't very helpfull to say:
  57.        "C's  printf() is simmular as pascals writeln(), but with ..."
  58.  Aside from being false, it also not clearifying the problem. Not in
  59. any formal/secure manier.
  60.  Of course it helps to "talk it over" or tho learn a pascal-programmer
  61. to write C. but that is it.
  62.  
  63. Second, after some kind of intro about type-model, there is no
  64. coupling between that type-model (or Catalysis) and the original
  65. -- intressting-- problem: the differance/simularity between data-driven
  66. and behaviour-driven.
  67.  
  68. ---GAM
  69. "This should be a jolly quote"
  70.